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Description 

FIELD OF THE INVENTION 

5 y. I ^£ZSS ton relates to a processin9 system and a method for hand,ing a ^ of services wi » 

BACKGROUND OF INVENTION 

10 [0002] Data processing devices are used for the widest range of increasingly versatile applications providino services 
ranging from, e.g editing of text documents or spread sheet applications to complex software sZlZ ^ co^- 
a.ded des.gn systems or systems adapted to manufacturing, purchasing, computer-aided banking etc FuZ t 

^SX^T SOttWa ? aPP ' iC . a ti0nS are emP, ° yed " fie ' d ° f PerS ° nal S " rviCeS ' *»r Phonal" data organ- 
izat,on, mobile communication applications like mobile telephones or hand-held computing devices or other services 
'5 provided or computer networks like the Internet. services 
[0003] The more elements are involved in a computer-supported service environment, where communication takes 
s' s"m toavoTabu:: T°**' 'V™ " " * ^ authentication of each uTer of such a 

ZZZ ^T USer " SPeCrf,C ' PerS ° nal ^ " any ° th6r data related to *he — ct operation of the 

20 !,nH 0 L h H H W r er ' WhNe " Umber ° f com Puter-supported applications is significantly increasing overtime concepts 
and methods for appropriate authentication of a user of such a system still rely on an individual authenSion of the 
user or each single service. In other words, when accessing multiple services in the computing en ironmen th uler 

E i V ' f aCh Sln9le S6rV,Ce an associated toS-in mechanism will require authentication of the user e g 
through submission of a user name and a user password, as for security reasons it is often not acceptable to keeo 
passwords ,n related memories and pass it between different service applications acceptable to keep 

[0006] While an authentication functionality may be easily implemented in a "closed" environment such as an od 

"VSSSZ 0 : TTT mputer or a main frame - where app,ications and interacti °- «3 exc c h h a a n s ge a ^ a 0 t p a" 

I T . a .PP llcat,on llke an application carried out using a plurality of data processing devices in a comeS 
moZ ' r rea ,Zati ° n ° f an aUthentication f-ctionality may become complex and cumbersome ' 
S ic ' f 3 US6r '" teraCtS with different services °n dWerent data processing devices, currently an individual authen- 
th ^ Up ° n , lnitlalisation of each ^ service on the respective data processing devices Thfe app.tes 
fnnno f„ USer prev,ous| y submitted tnis information to a plurality data processing devices PP 
£ !L M ° re ° Ver '. as authentication mechanism of the individual services running on the data processing devices 

s further eo ~ and ■ becomes j ™ to p^5~ 

[0009] Still further, another severe disadvantage of existing solutions is a repeated request for authentication durina 

LZTJl °" nteraCt '° h n b f een the user and the com puting environment, which each time intern^ * ^vistn o" 
services to the user, thereby reducing efficiency of user interaction. provision ot 

SUMMARY OF INVENTION 

Z\ ?! l^Z^nT^ * 1 d6Sirable 10 imPr ° Ve effiCiePCy ° f USer a uthentication in a computing environment 
L?!h \ AcCOrd ' ng t0 an exam P |e . managing a plurality of services at a session management unit includes- - receiving 
authentication information from a session processing unit adapted to handle a service session d Sd into a plu3 

slrTe' C ofthe POn Sati0n ° f 3 S6rViCe ' and - retUmin9 3 S6CUrit V toke " for '"»-«^ ° Tet^slZulZ 
service of the service session wrthout repeated submission of authentication information. Thus, e g a user does no 
need to repeatedly submit authorisation information for different services 

[ °° 1 f ] , Adv antageously returning the security token to the session processing unit may be effected only after sue 
cessful venf.cat.on of the authentication information. Thus, it can be avoided that, e.g., a frauduSnt user obtains a 
security token without submitting valid authentication information rrauau.ent user obtains a 

[0013] Further, a service host may be identified for each service request submitted by the session processing unit 
and he serv.ee request may be forwarded to the identified service host. Thus, e.g. a plurality of serv^e hosts mav be 
involved ,n providing services while avoiding repeated authentication of a user * ^ 

™It f r' Ce data !™ y be r6CeiVed at the S6SSi0n management unit in response to the processing of the service 

SST Jf 7 , d the SeSS '° n P rocess, ng unit may be channelled through the session management unit 

[0015] Alternatively, or ,n addition thereto, a direct forwarding of service data from the service host to the session 
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processing unit may be effected in response to the processing of the service, e.g., to avoid resource intensive routing 
of data through the session management unit. 

[0016] A session context information may be maintained, comprising at least the security token assigned for the 
service session, the authentication information, a list of services activated during the service sess IO n, and a list of 
connection points to related service hosts. 

[0017] Further the session context information may be maintained in a centralized manner at the session manage- 
ment unit. Alternatively or in addition thereto, the session context information may be maintained in a distributed manner 

5oi8] Se Furthe° S at least one service connection may be returned to a service host in addition to the security token for 
direct contact of the session processing unit to the at least one service host. 

[0019] The session processing unit may be located at a client side and the session management unit may be located 
at a server side to remotely communicate with the session processing unit. Accordingly, the invention may be realized 

in a distributed system. .. 
[00201 According to another example, handling, at a session processing unit, a service session divided into a plurality 
of services may include: - transmitting authentication information to a session management unit upon initialisation of 
a first service; and - receiving a security token for initialisation of each subsequent service of the service sess.on without 
repeated submission of authentication information. 

[0021] Further it may be evaluated whether a new service request requires a new application module, further in- 
stalling the new application module at the session processing unit in the affirmative case, and assigning the sess.on 
token and optionally service connection points to the newly installed application module. 

[0022] An authentication window may be set up for input of authentication data at a display, and the authentication 
window may be set up as a browser window. At least one of the services of a service session may be a Web service 
and the Web service may be a browser for browsing through data in a network of data processing devices. <• 
[00231 According to another example, a program may have instructions for carrying out the above operations. Further, 
a computer readable medium may be provided, in which a program is embodied, where the program is to make a 
computer execute the above operations. A computer program product may comprise this computer readable medium. 
[0024] Further embodiments of the invention are disclosed in the claims. 

DESCRIPTION OF DRAWING 

[0025] 

Rg 1 shows a schematic diagram of a processing system adapted to handle a plurality of services 

according to the present invention; 

Fig 2 shows a flowchart of a method for handling a plurality of services according to the present 

invention; 

Fig 3 illustrates session processing context from the viewpoint of an endues in the sense of the 

present invention; 

Fig 4 illustrates a session management context from the viewpoint of a session management do- 

main in the sense of the present invention; 

Fig 5 shows a flowchart of a further method for handling a plurality of services according to the 

present invention; 

Fig 6 shows a flowchart of a method for terminating a plurality of services according to the present 

invention; 

Fiq 7 illustrate different scenarios for interaction between the session processing/handling domain 

and the session context/service domain according to the present invention; in particular for a 
client server distributed computing environments; 

Fi g 8 illustrates the combined provision of security token and of service connection point(s) accord- 

ing to the present invention; 

Fig . 9 illustrates the combined provision of a security token and related service connection point(s) 
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together with a service support verification according to the present invention; 

Fi 9- 1 0 shows a flowchart for extending the available functionality at the end user side for the provision 

of additional services without repeated authentication according to the present invention; 

F, 9- 11 illustrates different ways to achieve service support evaluation according to the present in- 

vention; 

Fi 9- 1 2 shows a client-service system using the single authentication process for a plurality of services 

according to the present invention; 

Fi 9- 1 3 illustrates the interaction between a session handling domain and a service managing domain 

for a distributed client-service system; and 

Figs. 1 4(a) and 1 4(b) give a more detailed insight into the interaction between the session handling domain and the 
session management/processing domain according to Fig. 13. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENT 



[0026] In the following an embodiment of the present invention will be described with respect to Fig. 1 . 
[0027] As shown in Fig. 1 , the embodiment realises a processing system 100 dividing into a session processing unit 
1 10 and a session management unit 120. The session processing unit is adapted to provide and use specific function- 
alities with respect to different services to an end user. On the other hand, the session management unit 1 20 is adapted 
to provide those functionalities with respect to service(s) not being handled at the end user side, such as administration 
of user data, authentication information verification, identification of the requested service(s) etc. 
[0028] As shown in Fig. 1 , the session processing unit is arranged to submit a security code, e.g., a password and 
a user name, to the session management unit for subsequent verification. In response to the submitted security code 
the session management unit 120 will then provide a security token to the session processing unit 110. Further, the 
session processing unit 1 1 0 is adapted to use this security token for subsequent interaction with the session manage- 
ment unit 120 such as request of a further service(s) without a repeated or authentication or in other words repeated 
submission of user name and passwords. 

[0029] The present embodiment aims at improving the efficiency of user authentication in a computing environment. 
Repeated user authorization operations are cumbersome and may deter a user from requesting services. 
[0030] To avoid repeated user authorization operations it should be understood that each single service typically 
divides into different service aspects of processing, e.g., I/O functionality, data display functionality, computing, etc., 
and further service management, e.g., administration of user data, password data, etc. Also, service management 
relates to the question where a specific request for a service will actually be processed, e.g., on which data processing 
system in a distributed computing environment. 

[0031] From the above, it should be clear that end users may have access to either a single device or a plurality of 
devices being adapted to service processing, e.g., user authentication, data display, etc. 

[0032] On the other hand computing device(s) handling service management are not under control of end users. 
Therefore, an end user has to authenticate towards the service management domain - i.e., the computing device(s) 
handling service management and service provision to end users. However, within this service management domain 
not for every single data exchange/service activation a related authentication is necessary. 

[0033] The consequence from this is that once an end user has achieved a first successful authentication towards 
the service management domain, there exists at least one data processing system in this domain - e.g., access or 
entry server - that has verified the correctness of the authentication information. From this, it becomes clear that a 
repeated authentication towards a further unit in the service management domain becomes obsolete when information 
about a first valid authentication within the service management domain is transparent to all other units in this domain 
after such a successful authentication. 

[0034] A further operation towards the achievement eliminating repeated user authentication operations is then the 
establishment of a mechanism that allows the end user to indicate to each data processing device in the service 
management domain that it has already achieved a successful authentication during a subsequent access to this 
domain. 

[0035] Heretofore, it is proposed to receive authentication information, e.g., a user password and a user name, upon 
initialisation of a first service of a user, and then to generate a security item equivalent^ referred to as security token 
or security code in the following. 

[0036] Upon initialisation of a further service the end user may then use this security token for access to the service 
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management domain simply by adding the security token to the service request before submission of the service 
SST -herupon -P--™ 

IS 1 ^ntfound that it may be of benefit to summarize a plurality of different services and re.ated requests 
use this token for initialisation of a plurality of services at a serv,ce management doma.n durmg a serv.ce 
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•Hon ol new software. Oos such typical axampte would be tlta use of a Web browse, by an and user wSh.^li 
tor so™ sp^crac M, «K. audio or video requires ». i„s,„la,io„ of a rotated audio ^1:23 

[0061] The security token may be any kind of information allowing an identification for the ouroose of e a nht«in- 
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Invention , .ecu,!* roKen ma, also be provided ela a ohipoard o, ^^^^'^^'S^'^: 

9 ™Z™:tt^ are on* examples to, .he pr.s.n, M. and not to be eonsrroed as 
limiting the present invention. n ^ XAinr ri an ri a user name for authentication has been 

processing system o, b, corresponding software op jMDn^M W « | ^ 

Fudnentttenotedtnataeompotenmadab— 

=e,^^^ 

ZSKSS St^SSSSSSSK^: compote, program pnadoo, may be p.o^d 

SETS S - - — - - -—V- "TT F * 2 

an entity external to the processing system e.g., after ™™ 1 user and thus can be used as a proof 

S^7£«:M ^rSr^^X^--^ obanged. oootd 

SKS5^iS!^~^ «-"*■ "» " h9nKMton 01 ,he suBm " ted use ' name ""*" 

„o,d may be repeated «, I .later time. intoim „ ion „ m . 

EES aneiune 5£tS ™™ - - e— - .nrormar.o. a M o, services 
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»Hm£Jt Un ? 0na f ,ity ' 6 T diSP ' ay functionalit y. local computing, etc. In the latter case, the functionality relates to the 

ZTST" r' data ' PaSSW ° rd data ' and alS ° the pr ° Visi0n of service data »• display data or data ^ response 
to a data base interrogation to the end user. response 

[0076] Therefore, the provision of a service or of services for an end user may be considered a* fall,™ into a „ «. h 

se^ce pr^ ^ ^ **" Pr ° CeSSin9 ° f related ^ and excha " g * °< di^SSTS 

S L" , n ll0 ! Vin9, 3 fUfther embodiment of the i^ention will be described with respect to Fig 3 
52h hJth h 6XamP,e f ° r 3 SerViCG handlin9 COntext where « is assumed that the service request 

or ™ V 7 I" 86 ' IS " am ° ng ° therS " re ' ated t0 3 bf0WSer a PP""tion. A browser application can be an pl j 
aPP " Cat,0n Pr0grams a,lowing a convenient browsing through information or data available > in disSed 
ZT, T ? nV,r ° t nmentS SUCh aS the ,nternet « ™V ^her network including local area networks. A TZVer a^p caS 

Forth X t T d0Wnl ° ad d3ta 3nd fUrther to transmit data betwee " Cerent data proceJlg SevS 

Further, a browser application, appropriately configured or equipped with appropriate amendment or aM\oZc^ 
ules, sometimes termed plug-ins, may be enhanced with further functional to access or proces soSc kinds oi 

r d r =rm^ 

E Jl Sh ° Wn !" 3, SUCh P,U9 " inS are additi0na ' SXamples for what mi 9 ht be «"ated to a service request A 
Plug-,n may generally be a p,ece of software which may be added to any kind of larger software applicator such as 

th^drZ^ Pl,Cat,0n ; ! he ab ° Ve eXemP ' ary t6Xt Pr ° CeSSing abb,icatio " ° r an V «hor service nJS^T^^ 
dn^ f fUnCt !° na ' ,ty ° f the ' arger SOftware a PP"cation, for example visualisation capabBlSes for certam types of 
SP8C ,r CeSSin9 capabi,ities ° r simi,a '- A Plug-in may be added to the larger software applfcat on qen 
erahy at any des.red time, provided that the larger software application is equipped to receive Tnc nteoTaS he TJT 
m. The code for the plug-in may be obtained from any source, such as over a clpu^nXo* froml dl storLae 
med.um or similar. Alternatively, a plug-in may also be a piece of hardware adding funcfenaTy ol ^Zo< 

Som ar Z7^T; or a co T at r of auxiiiary soft - and hardware to enha - e °™^™z or 

kSUL 9 ' ar that ' general,v - servte e handling with respect to an end user may be related to 

different services requested by the end user where different services relay on different application modules e a nrl 
vK.ng browser and/or plug-in functionalities. Underlying this level abstraction, there 2 a furtheTs^ce provision 
related level, i.e. bemg related to the question to which data processing devices - e g web service aoo^ ° a Z« 

ESS Fin I T 1 : 9 ' 3 fUrther embodiment of the indention will be described with respect to Fig. 4 q 

V f 5f SerV ' Ce management as counterpart to end user oriented service handling With respect to 
taSrnt f d,fferent h SeWiCeS - Rg - 4 illustrates that a management of different services is achieved thZTel 
l e Ji n n °\ SeS T S that C ° nStitUte 3 SUmmary ° f different services witn res P e ct to a single end user in o a se Jce 
fn 1 h ? tyP ' Ca eXamP ' e ° f SUCh 3 S6rViCe SeSSIOn mav be a P |ura,itv of services being provided to he end user 
ran™ FT 6 : rS,ated SerViC6S and P ' Ug - in re ' ated SerVices ' as «empnned with respec? to Kg 3 ' 
?' 4 j" UStrat r that session management relates to the administration of a plurality of session related data 

L 22T 6 US6rS ' Sing ' e US6r rUnS 3 SeSSi ° n and for the session management relatec 'da a is ma mafned 
as sess.cn management context, i.e. the related user name and user profile. Here, user profile may be static or dynamic 

user pnonty, etc. Each session management context also comprises the security token which has been returned toth* 
end user upon successful authentication, and further a list of activated services and related Sn^Jion ooimto h! 
service providing data processing systems, once a security token has been provided, I aSion to thS aSl to 
mstaS Z*7 1 T S T management ma V als ° comprise a list of services supported so far - e g tluqh 
nnolf . re ' ated a PP |lcat,on modules or application software at the end user side 9 
m™n\ ^ f th3t eaCh Sing ' e S6SSi0n mana 9ement context may be maintained in a random access 

fnnff . following, a further embodiment of the invention will be described with respect to Fio 5 

[0086] According to the embodiment shown in Fig. 5, it is proposed to submrt a secur ty codl of any kind as outlined 

above ,n an operation 510. After a successful initial authentication in operation 510 the^eTsThen DroSd^ Zr S 
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15 



20 



25 



a specific service to a specific service host ^^^J^SSSS^uld be to assign a specific end user 
assign at least one end user to a specrfic serv,ce host. f ^""J»^^ ^ management domain. All these 
group to either at least one service host or 

examples are to be considered as non-hmf ng for ^^^^^ token and the appropriate connection 
outlined above. invention will be described with respect to Fig. 6. 

.. S3 r e r^~ - session - or ,n other words to the 

S of session-related data and disconnection of ^Z'T ^re^se a session through submission of 
0089] initially, in operation 610 the end user will ^^^^^^^ the further optiona. 
a related request. Then may follow the opt.onaloperat.on 620 *y f.nahze Then, in operation 640 the 
operation to save service-related data to avert waste "jJZf JSSSS processing domain and further 
session-reiated connections between the ^^^^^^^^ contact data may be saved, 
to a service host are disconnected and in ope at.on 650 9 ratlon 640 and 650 may as well be 

e.g., for the reason of debiting, auditing, and/or serv.ee 'ecovery« ~ ur ^;°P g furtner setvice session, 

reverse. Finally, in operation 660 the security token ^"^^^^^^ one may choose freely 

Eenar^^ 

TudSeo gaLs may allow for an ^^^^.S^^Z^d shutdown of a service session 
[0091] While above, the efficient support of a s ngle ^^"^^^^ during tne on-period of such service 
has been discussed, it should be noted that ^^^^^^^^ One'example would be to 
sessions allows for the implementator, of valuable "ectamsms for s ^° rt ° Q sona| . bound datav etc. Here, 
take specif ic care of security-sensitive services, l.ke remo e ^^^STZ security token at the session 
one example for security token management would be to block the al ^ a ^ that a security token provided for 
management domain after a service-specrf.c P-^^J^^"^ of time no person has access to 
remote banking will be blocked after an hour *°< h * a ^ 
suchabankingaccountAfurtherexample would betochange^ 

through repeated provision to the end user increase the security level for 

provided with security tokens at certa.n po.nts in X'Thp ^nSE^f sSri tokens could be that the security tokens 
the ongoing service session. Yet another example ^^ d ' m ^ each security token is only provided for 

are provided in away dependent on the ar ea of app ...cat. ^^^^^J^m be that for charged 
a specific country, region in a country ete. Yet t ^^^^^^^J ntf deposited a sufficient amount 
services a security token is only prov.ded when the re ^T^T^Z »Z one could imagine that a continuous 
of money wrth the service provider in the se^e ™™**™^™ n manaae ment domain and that a 

monitoring of the deposited serv.ee compensat.on ™°™ U **f™MX of money is no longer enough to pay for the 

espect to Fig. 3 and the session management doma.n/context ^^^^^^^ at least one client 
would be the application of the client/server architecture wherej ess^n h andhng «^^^ fl Mlnfl svst em. 
data processing system and session ^manage server data processing systems 
The client data process.ng systems then set up ise ^^°j manageme ^ domain there may be the server or 
set up the session management doma.n. Further in the session ma y se|vers 
plurality of servers handling session management as ^^"^J v|ei wll , alS o be referred to as 
provide services and related response data or signals. 
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mm "piT'rTht T "* °° M ** """ ' edUCe °" P ' O0eSsin » "> »» ""nagemem domain 

similar H * P arameters « etc., and may include a command or 

--~h^ 

Which oparation la optional - and hanSS ZZSaT^n ^ S "™ !e *" ma * ver "» ,te «*» - 

S ;L!^rar ther ° Pti ° n Where ^ ^ ^ ^ "*«« are avai,a b ,e in the 

r the service host Pro L ds ~£xssssz^^ 

EH ^^^^:^^^ n "T een f B SeSSi ° n d0mai " 3 S6Ssion -^men, 
agement domain. Furthe Examples o, ^^^T^^^ " *" ""^ tofcBn the S6Ssi0n man ' 
-nagementdomainandth^ 

f h e^a^^^^ 

user for interaction for the oJ^^Z^ZV" **" Pr ° CeSS,n9 ^ «*• a client ' us <* * *. end 
foi 1 1 nl £ th ^ f0, ,! OWin 9' a related embodiment of the invention will be described with respect to Fia 1 0 

[01 1] One example is shown in Fig. 1 1 (a) to incorporate information on already supported services at the end user 
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side, e.g., into the session management context and then to compare a submitted service request with this list of 
^ supported services. Alternatively and as shown in Fig. 1 1 (b), also the service host may - upon processing of service 
W request - carry out an interrogation at the session management domain. Yet another example for realizing the interro- 
gation operation 1010 shown in Fig. 10 is illustrated in Fig. 11(c). Here, upon initialization of a service request, initially 
5 it is checked in the session processing domain whether the requested service is already supported. If the result of this 
operation is 'no', initially the related application module or software is installed in the session processing domain - as 
will be explained in more detail in the following - and only then the service request and security token may be submitted 
to the session management domain or alternatively to the service host. 

[0112] Referring again to Fig. 10, when the interrogation operation 1010 leads to the result that a new application 
w module is necessary, this new application module may then be installed at the end user side in operation 1020. Again, 
it should be clear that the application module may be either provided in hardware or in software. In the latter case, the 
application software may be provided through downloading from the session management domain or from an external 
storage media for which examples have already been given above. 

[0113] A further operation 1030 shown in Fig. 10 is related to the assignment of the session token already available 

15 before operation 1010 to the newly installed application module. Optionally, also service connection points may be 
assigned to the application module. The outcome of operation 1030 is that upon activation of the newly installed ap- 
plication module the application module may not only generate a service request but also extend the service request 
by the assigned session token and optionally service connection points for the submission to the service management 
domain. Therefore, all operations necessary for the activation of a requested service at the end user side may be 

20 achieved without interrupting the flow of service processing at the end user side, particularly without requesting a 
repeated authentication also for the newly installed application module. Therefore, after assignment of the session 
token to the newly application unit a further operation 1040 is the return to service processing. 
[0114] In the following, a further embodiment of the invention will be described with respect to Fig. 12. 
[0115] Fig. 12 shows a client server system using a single authentication process for a plurality of services already 

25 explained above. The client service system 1200 divides into at least one client unit 1210 and at least one server unit 
1 220. Without limiting the scope of the invention, one may assume as one example thereof that the client unit realizes 
the service processing/handling domain and that the server unit 1220 forms part of the session management domain. 
Further, as shown in Fig. 12, the client unit 1210 has a display unit 1230, a service application unit 1240, a token unit 
1250, and a log-in unit 1260. Operatively, the display unit may display l/O-related and service- related data to the user 

30 of the client unit 1210. Further, the service application unit supports all processing with respect to provision of services 
to the user of the client unit 1210. Further, the token unit 1250 supports all functionality described above with respect 
to the security token, and the log-in unit 1260 supports all functionality being related to the authentication of an end 
user, as outlined above. 

[01 16] As counterpart to the log-in unit 1 260 of the client unit, Fig. 1 2 shows that also the server unit 1 220 has a iog- 
35 in unit 1270 for reception of the authentication request from the client unit 1210 and forwarding to the authentication 
and session management unit 1280. In addition, the server unit 1220 comprises a service management and context 
unit. Operatively, the log-in unit 1270 in the server unit 1220 is the low level unit for reception of authentication infor- 
mation at the server side. On a higher level of abstraction the authentication unit will then verify the submitted authen- 
tication request for submission of a security token back to the client unit 1210. Optionally, the authentication unit and 
40 session management unit 1 280 may also provide service connection points to the client unit 1 21 0. Further, the service 
management unit 1290 may also maintain the context of a session as explained with respect to Fig. 4. 
[01 1 7] While above different units both of the client unit 1210 and the server unit 1 220 have been explained, it should 
be clear that these units may as well be combined with each other or split up into further units. Also, each single unit 
may either be realized in hardware or in software or in a combination of hard- and software. Further, the client server 
45 system explained with respect to Fig. 12 may be adapted to any distributed computing environment known in the art, 
i.e., local area networks, wireless LAN networks, or any other kind of system relying on the client server paradigm. 
[0118] In the following, different examples for the application of the client server architecture shown in Fig. 12 will 
be described with respect to Fig. 13. 

[0119] Fig. 13 shows an example for the interaction of the service handling domain and the service management 

so domain, with a more detailed reference to a distributed client server system. 

[0120] As shown in Fig. 13 the session handling domain divides into a plurality of client processing systems 1310, 
1320 and a plurality of server processing systems 1330 to 1380 in the session management domain. Without limiting 
the present invention it may be assumed that one of the server processing systems, i.e. server 1380, is an entry server 
to the session management domain. The further servers in the session management domain 1330-1370 are servers 

55 acting as service host(s). 

[0121] As also shown in Fig. 13, the change of data between the session handling domain and the session manage- 
ment domain and also within the session management domain may be classified into different categories. A first cat- 
egory is the exchange of authentication and session management related data (solid line), further, the exchange of 
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P ay£d daTa a bo e th Shinfhf ^ ^ mana 9 ement domai " gashed line), and the exchange of service 

^mZX^^^TT T 1 Cl !! ntS 1310> 1320 initia " y S6tS UP 3 -—nidation dialogue with 
on in^rtion t exchange of authent.cation data and for receipt of a security token, and optionally information 
; n *" P° l e - numbers assi 9" ed to ^Plication running on the service hosts 1330 t ,1370 SuteTquent 
?380 which T m t^ T T inVen,i ° n W0U ' d 66 th3t dient Unit 1310 "^ests a service from the entry se"e 
So V ~f? VenflCat,0n of a submitted security token, forward the service request to the sZiceZZ 

rSSr S6rViCe reqUeSt ' ^ h ° St 1330 ^ *«* — ba <* the servic^o^ 

Slim uniU^and^Z'^r ^ 13 W ° U ' d ^ SerViCe 1380 receives a service request from the 

chen unit 1320 and forwards the service request to the service host 1360. After generation of the se^ice respond 

zszszz rssir may verify the — =s 

thfS, Th ' S distributed client/server system supports flexibility in service processing Eq a first examole would h„ 
tha d.fferent ciients - i.e. different end users - are handied with different priorities, this case teZfeZr^ 

Sl261 Anoth^ L 3 Pr, °, rity qU ?w Ue K PU r n9 ^ ^ With hiaher P " 0ri * before with owe S 

equL^thin th^.? 6 *" implementation of a '° ad Glancing mechanism for the handling of service 

requests w. h.n the session management domain. Here, before forwarding a service request to the specific seZ ce 

out ™?,J T T 6 380 initia " y dStermine the '° ad on each ^ng'e service host 1330 o 1370 the £SE 

sli^ce and h TT 31 6aCh SSrViCe h ° St 1330/137 °' and the " Select the service host providing the requested 
service and having the lowest current processing load imposed thereon requested 

manlL™ ' a H° ther TT' 6 W ° Uld be t0 SP6Cify 3 S6CUrity token t0 9 ether with a Purred sub-domain in the session 
roiM? T k JTT ° r processin 9 of services guested using the security token. 

2 ' should also be notedthatthedistributedclient/service system is well adapted to supportbrowserapplications 

fmm^f ir c A ^ em0t 7 iSUaliZati0n Pr ° t0C0 ' ° r mn time environment component service is to ensure convenient access 
from a first computer system to resources available at a second computer system - in the present Examole 1 v^if 
cation or group of applications or modules which enable a user at a client unft to ^nl^SSZl^ZSl uZ fn the 
IZZZrT™" d , main ** inf ° rmati ° n pr0Vided bv a se ™ in server managed doma e a he" 

EH™— 

SIS L" followin 9' a further embodiment of the invention will be described with respect to Fia 1 4^ an H 1 a,m 
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r0136l Then in operation 1406 the client unit receives and displays the authentication frame for subsequent user 
nput of aTenZ2"T«. e.g.. user name and password. Another example would ^^^^^ 
erated locally at the client unit for display in operation 1 406 for reduct.cn of amount of data to be exchanged between 

mSH ^ht a lpe e rS UoTthe user inputs the actual authentication data like user name and password for trans- 
Eon to !he se^r.n the related operation 1 408 the entry server will receive the authentication data and ver.fy th. 
m.ssion to the server, in me H evaluates whether the authenticate has been suc- 

data M H therelltT'n the X^r^^3S WbrmaMon to the client unit which will then handle the 
be the closinq of the session between the client unit and the entry server. flono . 

storage in a stoTage media external to the client unit. Optionally, together wfth the secunty token also session reteted 
data L service connection points may be maintained for the client unit for subsequent 3peedof3erv.ee host ^ooe^ 
foi391 Then as shown in Fig. 14(b), in operation 1412 there is a continuous evaluat.on whether an end user has 
SLd a se^e request to the client unit. If the result is No, the interrogation operation 1412 w.ll be repeated. 
SlSse^ 

2 toe clien t un t ounng operation 1 41 4, as exemplified above, with respect to Fig. 10. Subsequent hereto, the serv.ee 
processing proceeds ?o operation 1415 to generate a service request including the security token for transm.ssion to 

To^T According to a first scenario the generated service request will be forwarded to the entry server which then 
Lv^uL a^d vtrfies the submrtted security token in operation 1 41 6, and after identification of an approbate serv.ee 
hosf^rds^ 

1418 tZ serv ce host will then generate the service response data and forward the service response data to the chent 
HI .1 opera ton 141 Tthe client unit receives the service response data for local processing at the d.en unrt , _ 
[0 42 A -ond scenario illustrated in Fig. 14(b) is the direct forwarding of a service 

service host According to this scenario the service host receives the serv.ee request with the secunty token for- eval 
ua ion oftoe aHowabilfty of the submitted request on the basis of the submitted secunty token ,n operat.on 1 420 .JT the 
^T<?tr^«^SilIon to positive. th« sarvlo. ho^lhen pro««d»l» opeiaBon 1*18forftirther prooe«;.ng of th« M rv»e 
reouest as previously explained. Otherwise, the service host may reject the submitted serv.ee request. 
01431 FurthTsubsequent to the handling of the service response data in operation 1419 at the cl.ent unit there 
Sow! an operation 1 421 for cheeking a log-out instruction at the client unit. Here, log-out may be related to a sess.on 
on Z one °5nd or to shut down oHhe client unit itself . If the result of the operation 1 421 is "no', the process flow 
mav branch back ° G operation 1 41 2 to check on further service requests at the client unit, if the result of the operat.on 
7421 .s yes ^SS^SZl inform the entry serve about the log-out instructions, in operation 1422 the entry .server 
Jm hen aenerate and transmit a request to terminate the session including the release of the secunty token to the 
cl I f onder tor the exa mp , e distributed session context is explained above with respect to Fig. 7 the entry server 

w^so'^ 

Session shut down Then, in operation 1423 the entry server will release the security token and the sess.o context 
fn other words once the security token is released it may be used for a further service sess.on set up^ The empo ary 
" of the security token increases security wrthin the service management doma.n since only the time penod 

SS^^^I. maintained at the entry server or any other data processing device with.n the S ess.on 

management domain may be used with this security token. Ho e ™h e H with reference to the 

[01 44] While above different examples and embodiments of the invent.on have been described ^ reference to th e 
drawing it is to be understood that these are non-limiting to the scope and gist of the present .nvent.on and hat a 
oL r rn ski.ted°n the art is readily prepared to realize such modifications and variations. A f.rst example tor th.s s that 
white above a s ell o n h as been described wrth respect to a piurality of services it may also be possible to set up a 
"note sesin or each requested service. Further, It may be possible to use a single security token for ap^rahty of 
end users thus achieving a shared token mechanism which is of particular advantage for services shared by a plural. ty 
of end use s e g video games, shared data base maintenance, etc.. Another example would be the prov.s,o , o the 
same ^securrty token to the same end users logging in at a plurality of client units in the sess.on handling domain to 
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™«rT e "T e ° f 3 PlUraMty ° f SerViCS mana 9 eme "t contexts in the service n^Tagement domain 
[0145] According to another example, a session management unit may have the following constitution: 

1) Session management unit for managing a plurality of services including 

- a code section having instructions to receive authentication information from a session processing unit adapted 
to handle a service session divided into a plurality of services, upon initialisation of a first service, and 

- a code section having instructions to return a security token for initialisation of each subsequent service of the 
service session without repeated submission of authentication information. 

fifT?^ management unit acceding «° D. including a code section having instructions to return the security 
token to the session processing unit only after successful verification of the authentication information. 

ZlZT" management unrt wording to 1 ), including a code section having instructions to identify a service host 
Ie^ceho e sT CereqUe S ^ 

tnlZ™LTT ement Unit aC f° rdin 9 to 3 >- includin 9 a cod * action having instructions to receive service data 
processing "unit Pr ° CeSS ' n9 * h ° St f ° r subse ^ '".warding *> the session 

wlfninn °f manage H m f n f t unit wording to 3), including a code section having instructions to effect a direct for- 
TerSce ^ *° S6SSi ° n P rocessin 9 unit in «»P°nse to the processing of the 

l^tfZ management unit according to 1), including a code section having instructions to maintain session 
context nformation comprising at least the security token assigned for the service session, the authentication 
information, a „st of services activated during the service session, and a list of connection points to rented Sice 

7) Session management unit according to 6), including a code section having instructions to maintain the session 
context information in a centralized manner at the session management unit. 

llTeT^JSZT^Tf^ tQ 6) ' inC ' Uding 3 C ° de SeCti ° n havi " 9 instructions * ^intain the session 
context information in a distributed manner at the service hosts. 

9) Session management unit according to 1), including a code section having instructions to return at least one 

untt o ,h e °" M *T 3 S6rViC l h ° St " addm0n 10 the SGCUrity t0ke " f ° r direct conta ct of the session Processing 
unit to the at least one service host. y 

10) Session management unit according to 1), including a code section having instructions to effect set-un an 
authentication window for input of authentication data at a display. P 

Htntf management unrt according to 19), including a code section having instructions to effect set-up of an 
authentication window as a browser window. 

IZctonZ mana9 f ment unit according to 1), located at a server side, and including a code section having in- 
a dient stde. <*>™™™*e with the session processing unit, the session processing unit being located at 

According to another example, a session processing unit may have the following constitution: 

13) Session processing unit for handling a service session divided into a plurality of services, including 

" r n ^t a S t eCti °? h T? inStmCtions to transmit authentication information to a session management unit upon 
initialisation of a first service; and H 

- a code section having instructions to receive a security token for initialisation of each subsequent service of 
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the service session without repeated submission of authentication information. 

141 Session processing unit according to 13), including a code section having instructions to receive > the security 
token at the session processing unit only after successfu! verification of the authent.cat.on .nformat.on. 

151 Session processing unit according to 13), including a code section having instructions to effect identrfication 
o?L !S host fo^ach service request submitted by the session processing unit and for effect.ng forward.ng of 
the service request to the identified service host. 

IB) Session processing unit according to 15), including a code section having instructions to receive service data 
in !etponse to : the processing of the service request at the service host from the session management un,t. 

1 7) Session processing unit according to 1 5), including a code section having instructions to directly receive service 
data from the service host in response to the processing of the service. 

18) Session processing unit according to 13), including a code section having instructions to effect maj^" n f° 
of L?£3text Smation at the service management unit, comprising at least the securrty token assigned for 
the ^ sereleSn" the authentication information, a list of services activated during the serv.ce session, and a 
list of connection points to related service hosts. 

19) Session processing unit according to 18), including a code section having instructions to effect maintenance 
of the session context information in a centralized manner at the session management unrt. 

20) Session processing unit according to 18), including a code section having instructions to effect maintenance 
of the session context information in a distributed manner at the service hosts. 

211 Session processing unit according to 13), including a code section having instructions to return at least one 
servfce SKTS?;in*» host in addition to the security token for direct contact of the session processing 
unit to the at least one service host. 

?9\ Session orocessinq unit according to 13), including a code section having instructions to evaluate whether a 
new serv ce E^^ll a new application module, further to install the new application module at the session 
procesTg uX the affirmative case, and to assign the session token and optionally service connection points 
to the newly installed application module. 

23) Session processing unit according to 13), including a code section having instructions to set-up an authenti- 
cation window for input of authentication data at a display. 

24) Session processing unit according to 22), including a code section having instructions to arrange the authen- 
40 tication window as browser window. 

25) Session processing unit according to 1 3), located at a client side, and including a code sec ; i °" i ^3^ 

to remotely communicate with the session management unit, the session processing unit being located at a 
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server side. 
Claims 

1 . Session management unit for managing a plurality of services; comprising: 

- a reception unit for receiving authentication information from a session processing unit adapted to handle a 
service session divided into a plurality of services, upon inrtialisation of a first serv.ce, and 

. an authentication unit for returning a security token to inrtialise each subsequent service of the service session 
55 without repeated submission of authentication information. 

2. Session management unit according to Cairn 1 , wherein the authentication unit refcrns the security token to the 
session processing unit only after successful verification of the authent.cat.on information. 
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f^rS m h an ^ emen V Unit aCCOrdin 9 to claim 1 or 2 . ^rther comprising a service management unit for identifying 
a service host for each serv.ce request submitted by the session processing unit and for forwarding the service 
request to the identified service host. 9 service 

Session management unit according to claim 3, wherein the service management unit receives service data in 
SessTn u t 6 Pr ° CeSSing ° f the S6rViCe reqU6St at the service host for subsequent forwarding to the session 



5 ' ff^L m lT 9 f me, ! t K Unit aCC ° rding t0 C ' aim 3 ' Wh6rein the S6rVice ma "agement unit effects a direct forwarding 
of service data from the serv.ce host to the session processing unit in response to the processing of the service 

6 ' i e nwt n in m f ana9 r ent Unit aCC ° rdin9 10 ° f the C ' aimS 1 t0 5 ' com P risi "9 a context unit for maintaining session 
Sormlt io . :° n f COm . PnS,ng at least the securit V toke " for the service session, the authentication 

to related service hosr ,CeS and/ ° r ^ *" SeSSi ° n ' 3 " d 3 ^ ° f COnneCtion P° ints 

information in a centralized manner at the session management unit. 

information in a distributed manner at the service hosts. 

9 " ^i 0n , mana9eme [! t Unit accordin 9 to claim 1 • wherei " authentication unit returns at least one sen/ice con- 
"easZese ZZZO? " addifon * *" ***" *" *"* M " M ° f the SeSSi ° n prOC6SSin 9 unit t0 the at 

10 ' Snti.Tr 396 '?"* f Unlt aCC ° rding t0 °" e ° f the C ' aimS 1 tG 9 ' wherein the authentication unit sets up of an 
authentication window for input of authentication data at a display. 

1 1 ' afreasZr^th mSnt aCC ° rding t0 ° M °* th<3 da,mS 1 t0 1 °' Wherein the service management unit provides 
at least one of the services in a service session as Web service. 

12 ' t S h e .n S tir t mana9 ! ment T 11 aCcordin 9 to claim 10 ° r 11 ■ herein the authentication unit effects set-up of the au- 
thentication window as browser window. 

3. Session management unit according to claim 11 or 12, wherein the at least one Web service is a browser for 
browsing through data in a network of data processing devices. Browser tor 

4 ' fnrrim n o t T ana9ement * 006 ° f the C ' aimS 1 t0 13 ' wnich is located at a se ™ and adapted 

for remote communication with the session processing unit, the session processing unit being located at a cHent 

5. Session processing unit for handling a service session divided into a plurality of services, comprising: 

- a login unit for transmission of authentication information to a session management unit upon initialisation of 
a first service in a service session; and 

" f™tl^ nit I° r reCeiVin . 9 3 SSCUrity t0ken t0 initialise eaCh subse <^nt service of the service session without 
repeated submission of authentication information. 

i. Session processing unit according to claim 15, wherein the token unit receives the security token at the session 
processing unit only after successful verification of the authentication information. 

Session processing unit according to claim 15 or 16, wherein a service application unit effects identification of a 
^dered s^™ SUbmitt6d " ^ SeSSfon PrOCeSSi " g "* - - ~*- ^st 

- Session processing unit according to claim 17, wherein the service application unit receives service data in re- 
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sponse to the processing of the service request at the service host from the session management unit. 

19. Session processing unit according to claim 17, wherein the service application unit directly receives service data 
from the service host in response to the processing of the service. 

20 Session processing unit according to one of the claims 1 5 to 19, wherein the service application unit effects main- 
tena ce o sesstn context information at the service management unit, comprising at least the secunty token 
as^nedVor the service session, the authentication information, a list of services actuated and/or supported dunng 
the service session, and a list of connection points to related service hosts. 

21 Session processing unit according to claim 20, wherein the service application unit effects maintenance of the 
" session context information in a centralized manner at the session management unit. 

22 Session processing unit according to claim 20, wherein the service application unit effects maintenance of the 
session context information in a distributed manner at the service hosts. 

23 Session processing unit according to claim 15, wherein the service management unit returns at least one service 
cZecZTZ^ host in addition to the secunty token for direct contact of the session processmg un.t to 
the at least one service host. 

24 Session processing unit according to one of the claims 15 to 23, wherein the service application unit evaluates 
whether a new se^ice request requires a new app.ication module, further installs the new apphcation module at 
£ sessio^ Rising un« in the affirmative case, and assigns the session token and optionally service connection 
points to the newly installed application module. 

25. Session processing unit according to one of the claims 15 to 24. wherein the service application unit sets up an 
authentication window for input of authentication data at a display. 

26. Session processing unit according to one of the claims 1 5 to 25, wherein at .east one of the services of a service 
session is a Web service. 

27. Session processing unit according to claim 25 or 26, wherein the authentication window is arranged as a browser 
window. 

28. Session processing unit according to claim 26 or 27, wherein the at .east one Web service is a browser for browsing 
through data in a network of data processing devices. 

2«, Session processing unit according to one of the claims 1 5 to 28, which is located at a client side, and adapted to, 
f:^ Z^aZ with the session management unit, the session processing unit being located at a server 

side. 

30. Method for managing a plurality of services at a session management unit, including: 

- receiving authentication information from a session processing unit adapted to handle a service session divided 
into a plurality of services, upon initialisation of a first service, and 

- returning a security token for initialisation of each subsequent service of the service session without repeated 
submission of authentication information. 

31. Method according to claim 30, including returning the security token to the session processing unit only after 
successful verification of the authentication information. 

32 Method according to claim 30 or 31 , including identifying a service host f6r each service request submitted by the 
' session processing unit and forwarding the service request to the identified service host. 

33 Method according to claim 32, including receiving service data in response to the processing of the service request 
at the service host for subsequent forwarding to the session processing unit. 
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34. Method according to claim 32, including a direct forwarding of service data from the service host to the session 
processing unit in response to the processing of the service. 

35. Method according to one of the claims 30 to 34, including maintaining session context information comprising at 
least the security token assigned for the service session, the authentication information, a list of services activated 
and/or supported during the service session, and a list of connection points to related service hosts. 

36. Method according to claim 35, including maintaining the session context information in a centralized manner at 
the session management unit. 

37. Method according to claim 35, including maintaining the session context information in a distributed manner at the 
service hosts. 

38. Method according to claim 30, including returning at least one service connection to a service host in addition to 
the security token for direct contact of the session processing unit to the at least one service host. 

39. Method according to one of the claims 30 to 38, including effecting set-up an authentication window for input of 
authentication data at a display. 

40. Method according to one of the claims 30 to 39, wherein at least one of the services of a service session is a Web 
service. 

41. Method according to claim 39, including effecting set-up the authentication window as a browser window. 

42. Method according to claim 40 or 41 , wherein the at least one Web service is a browser for browsing through data 
in a network of data processing devices. 

43. Method according to one of the claims 30 to 42, wherein the session processing unit is located at a client side and 
the session management unit is located at a server side and remotely communicates with the session processing 

44. Method according to claim 30, including the release of a security token at the end of a service session. 

45. Method according to claim 30, including the modification of a security token during the time period a service session 

IS 3CtlV3ted. 

46. Method according to claim 44, including the finalization of activated services and the saving of related service data 
before release of a security token. 

47 ' tokln 0d aCCOrdin9 10 ° laim 46 ' fUrther including the savin 9 of session information before release of a security 

48. Method for handling, at a session processing unit, a service session divided into a plurality of services, including 

- transmitting authentication information to a session management unit upon initialisation of a first service; and 

- receiving a security token for initialisation of each subsequent service of the service session without repeated 
submission of authentication information. 

49 ' C '?T 48 ' inC,Udin9 reCeiVinQ the S6CUrity token at the session Processing unit only after 

successful verification of the authentication information. 

5 °' «,T°» t0 C ' aim 48 ° r 49 ' inC ' Uding effSCting identiflca «°n of a service host for each service request 

submitted by the session processing unit and effecting forwarding of the service request to the identified service 

51 ' ^t t h , Ti aCCOr< !i n9 w C ' ai T 48 ' inC ' Uding reCeiVing S6rVice data in response t0 the Processing of the service request 
at the service host from the session management unit. 
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52. Method according to claim 48, including direct receiving of service data from the service host in response to the 
processing of the service. 

53 Method according to one of the claims 48 to 52, including effecting maintenance of session context information at 
the service management unit, comprising at least the security token assigned for the service session, the authen- 
tication information, a list of services activated and/or supported during the service session, and a hst of connection 
points to related service hosts. 

54. Method according to claim 53, including effecting maintenance of the session context information in a centralized 
manner at the session management unit. 

55. Method according to claim 53, including effecting maintenance of the session context information in a distributed 
manner at the service hosts. 

56. Method according to claim 48, including returning at least one service connection to a service host in addition to 
the security token for direct contact of the session processing unit to the at least one service host. 

57. Method according to one of the claims 48 to 56, including evaluating whether a new service request requires a 
new application module, further installing the new application module at the session processing unit in the affirm- 
ative case, and assigning the session token and optionally service connection points to the newly installed appli- 
cation module. 

58. Method according to one of the claims 48 to 57, including setting up an authentication window for input of authen- 
tication data at a display. 

59. Method according to one of the claims 48 to 58, wherein at least one of the services of a service session is a Web 
service. 

60. Method according to claim 58 or 59, including arranging the authentication window as a browser window. 

61. Method according to claim 59, wherein the at least one Web service is a browser for browsing through data in a 
network of data processing devices. 

62 Method according to one of the claims 48 to 61 , wherein the session processing unit is located at a client side and 
the session management unit is located at a server side and remotely communicates with the session processing 
unit. 

63. A program having instructions for carrying out the method of at least one of the claims 30 to 62. 

64. A computer readable medium, in which a program is embodied, where the program is to make a computer execute 
the method of at least one of the claims 30 to 62. 

65. A computer program product comprising the computer readable medium according to claim 66. 
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FIG. 6 
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